ADFS Identity Provider architecture

This topic explains the possible architectures for using a Windows ADFS server (Active Directory Federated Services) as an Identity Provider.

The following sections give a basic description of the supported single domain ('Company A') or dual domain ('Company A' and 'Company B') architectures.

These are the general requirements for running ADFS as an Identity Provider:

  • All firewalls must be configured to allow user access to https://{IPS.domain}/{TENANTNAME} via HTTP(S) (either port 80 or 443). This needs to be accessible to users in both domains 'Company A' and 'Company B' for the Forest or Federation Trust architectures.
  • ADFS server addresses need to be within the Intranet Zone. For users in Company B: both Company A and Company B’s ADFS servers need to be in the Intranet Zone. For users in Company A: only Company A’s ADFS server needs to be in the Intranet Zone.
  • Latency requirements: The connection between the ADFS IdP server and Planning Space IPS server (or load balancer for an IPS cluster) must have a latency of less than 1 ms, that is, the servers need to be on the same LAN (and without bandwith or QoS restrictions). As per overall network requirements (see Hardware and software requirements), user client connections to the server infrastructure must be reliable and less than 150 ms (100 ms is recommended). Where latency is greater than 150 ms, or is not reliable, then an application provisioning technology (such as Citrix) must be used.
  • For SSO: the IPS Service Address needs to be in the Intranet Zone. A user must login to their local machine with the same account (UPN) that is authenticating against ADFS, and which is defined in a Planning Space 'SAML2' user account.

Single company AD domain

In this case all infrastructure and users are in one Active Directory domain ('Company A').


ADFS authentication setup for a single Active Directory domain.

Initial authentication flow (numbers refer to the numbered arrows in the diagram):

  1. A user initiates login to the Planning Space tenant website, https://{IPS.domain}/{TENANTNAME} .
  2. IPS Server redirects to the ADFS IdP server, where the user will log in via browser (note: to configure SSO for this situation depends on the browser software used, and is not covered in this guide).
  3. ADFS will send an authentication request to AD.
  4. AD authenticates the user.
  5. ADFS server will pass a SAML token to IPS Server (containing the user's UPN).
  6. User has completed authentication for IPS and can access the tenant website. From here she can download the Planning Space client application to her local machine.
  7. User does login to the Planning Space client application. All subsequent activity takes place within the client application.

Forest trust between domains

In this case, all of the Planning Space and ADFS infrastructure is in one Active Directory domain ('Company A'), and users from 'Company B' can authenticate against Company A's ADFS server because there is a forest level trust between the Company A and Company B AD domains. A LAN or VPN connection is required between the company ADs.


ADFS authentication setup for a forest trust between two domains.

Initial authentication flow for a user in Company B (numbers refer to the numbered arrows in the diagram):

  1. A user in Company B initiates login to the Planning Space tenant website, https://{IPS.domain}/{TENANTNAME} .
  2. IPS Server redirects to the Company A ADFS IdP server, where the user will log in via browser.
  3. ADFS server will send an authentication request to the Company A AD.
  4. Company A AD will push the request to the Company B AD via the forest trust.
  5. Company B AD authenticates the user.
  6. Company A AD sends the successful authentication to the Company A ADFS server.
  7. Company A ADFS server will pass a SAML token to IPS Server (containing the user's UPN).
  8. User has completed authentication for IPS and can access the tenant website. From here she can download the Planning Space client application to her local machine.
  9. The user is logged into Planning Space via SSO, after inserting her UPN username at the Planning Space client application login screen. All subsequent activity takes place within the client application.

ADFS Federation trust

In this case, all of the Planning Space infrastructure is in one Active Directory domain ('Company A'). There are ADFS servers in both 'Company A' and 'Company B'. Users in Company B can authenticate against the Company A ADFS server because there is a federation trust between the Company A ADFS and the Company B ADFS. Note that federation trust requires only an Internet connection (LAN or VPN are not required).


ADFS authentication setup for a federation trust between two domains.

Initial authentication flow for a user in Company B (numbers refer to the numbered arrows in the diagram):

  1. A user in Company B initiates login to the Planning Space tenant website, https://{IPS.domain}/{TENANTNAME} .
  2. IPS Server redirects to the Company A ADFS IdP server.
  3. Company A ADFS will push authentication to the Company B ADFS, where the user will log in via browser.
  4. Company B ADFS server will send an authentication request to the Company B AD.
  5. Company B AD authenticates the user.
  6. Company B ADFS sends the successful authentication to the Company A ADFS.
  7. Company A ADFS will pass a SAML token to IPS Server (containing the user's UPN).
  8. User has completed authentication for IPS and can access the tenant website. From here she can download the Planning Space client application to her local machine.
  9. The user is logged into Planning Space via SSO, after inserting her UPN username at the Planning Space client application login screen. All subsequent activity takes place within the client application.